Mobile Circuit Switched (CS) services supported by on GSM/EDGE Radio Access Network (GERAN) and Universal Terrestrial Radio Access Network (UTRAN) are used throughout the world. They allow a user to obtain telecommunication services with a single user subscription in many countries around the world. The number of CS subscribers continues to grow rapidly, boosted by the expansion of mobile CS services in countries with high populations such as India and China.
A Third Generation Partnership Project (3GPP) work item, “Evolved UTRA and UTRAN”, defines Long-Term Evolution (LTE), designed to improve efficiency, lower costs and improve services for 3GPP-based access technology. LTE uses Orthogonal Frequency-Division Multiplexing (OFDM) radio technology in the downlink and Single Carrier Frequency Division Multiple Access (SC-FDMA) for the uplink, allowing at least 100 Mbps peak data rate for downlink data rate and 50 Mbps for uplink data rate.
In addition to the Radio Access Network (RAN) standardization, a 3GPP System Architecture Evolution (SAE) work item has been to develop an evolved core network (CN) for LTE networks—referred to as the Evolved Packet Core (EPC) or simply SAE Core. The SAE core network is made up of core nodes, which may be further split into Control Plane (Mobility Management Entity, MME) nodes and User Plane Gateway (Serving Gateway and PDN Gateway) nodes.
LTE and SAE only support Packet Switched (PS) data transport, and so all services must be supported via a PS domain. However, existing GERAN and UTRAN provide both PS and CS access and services, and so for telephony services to be deployed over LTE radio access, an IMS-based service engine is required. There are several interim solutions to allow LTE/SAE access to CS domain services normally available via GERAN and UTRAN but these require the network to either support “CS over SAE/LTE” or sending the UE to one of the CS supporting Radio Access Technology (RAT). The solution focused in this invention is the later, specifically, the Circuit Switched Fallback solution
“Fallback” is the term used in the field of mobile telecommunications to describe the transfer of UEs, sometimes referred to as a “mobiles” or “terminals” in this document, in active mode from a “higher” radio access technology (RAT) (such as LTE) to a “lower” RAT (such as GSM or UMTS). In this sense, fall back is intrinsically “inter-RAT”.
Circuit Switched Fallback (CSFB), then, is a technique which allows the UE, normally camped on LTE for Packet Switched (PS) services, to make a Circuit Switched (CS) type call on a CS supporting Radio Access Technology (e.g. UTRAN or GERAN) providing overlaying coverage to the UE.
The eNodeB can use different methods to transfer the call from LTE to a CS supporting RAT. For CSFB to GERAN or UTRAN supported techniques in 3GPP include:
1) PS Handover (applicable to both UTRAN and GERAN)
2) Cell Change Order (CCO) with/without Network Assisted Cell Change (NACC) (only applicable for GERAN)
3) Release with Redirection with redirected carrier information (applicable to both UTRAN and GERAN)
The main discriminating factors between the different options for CSFB include the complexity of implementation and more importantly, the delay incurred in using the procedure.
Upon fallback from E-UTRAN (i.e. the LTE network) to Circuit Switched (e.g. GSM or UMTS voice networks) when moving out of E-UTRAN coverage the UE is required to re-measure the GSM radio environment in order to discover the correct Location Area, interrupting the call. This adds >400 ms of call setup delay which degrades the user experience.
To address this, it is known, from the Applicant's written contribution to the 3GPP TSG SA WG2 Meeting #77 (18-22 Jan. 2010) S2-100550, “Minimising Location Updates during CS Fall Back”, filed as a provisional UK patent application GB1000456.2 on 12 Jan. 2010, that for CS FallBack (CSFB) it is useful to align the tracking area boundaries with the location area boundaries of the “target RAT”.
Section 4.2 of the S2-100550 written contribution describes the use of location code counters within the eNodeB to aid this process. However, the implementation of these counters itself poses new problems.
It is useful, at this point, to explain a few of the abbreviations and acronyms used to describe location codes in 3GPP Standards: 3GPP TS 23.003 defines the Location Area Code (LAC) as a fixed length code (of 2 octets) identifying a location area within a public land mobile network (PLMN). This is part of the Location Area Identification (LAI) information element that can be coded using a full hexadecimal representation except for the reserved hexadecimal values 0000 and FFFE. This equates to 65,534 values which the network operator can assign.
The LAI is itself composed of the LAC plus the Mobile Country Code (MCC) and Mobile Network Code (MNC).
The S2-100550 written contribution, more precisely then, suggests that the eNodeB (eNB) could maintain location code counters for the most frequently received LAIs.
The eNodeB can determine the identities of Location Areas previously encountered by E-UTRAN attached UEs in any E-UTRAN cell. When each UE attached to E-UTRAN performs a Tracking Area Update the LAC is transferred to the eNodeB as part of the LAI within the Routeing Area ID (RAI)—which is itself within the Globally Unique MME Identifier (GUMMEI). If the LACs are collected over a suitable time period (e.g. up to and including 24 hours), and collated as a table of frequency of occurrence versus each of the 65,534 allowed LACs, the most likely Location Area that overlaps the E-UTRAN cell can be determined, as this will be the most frequent.
The new problem posed by this suggestion in the S2-100550 written contribution arises because an eNodeB does not know how many location areas may be indicated by the UEs performing inter-RAT Tracking Area Updates/Attaches. This can be particularly problematic at borders/airports where large numbers of different ‘last visited LAIs’ can be received within the RRC signalling messages from the different mobiles. In addition, it is important that the eNodeB counters react swiftly to any changes of the underlying 2G/3G coverage/cell/LA planning/configuration (e.g. if the 2G LA boundary is moved, then the hourly statistics from the eNodeB should reflect this.)
In other words, in E-UTRAN cells containing relatively high proportions of inbound roamers from other countries, or where network sharing or national roaming is allowed, LACs identical to some allocated in the serving network may be encountered, but these will have been assigned by a mobile network in a different country, or by a different mobile network in the same country as the serving network. Thus the LAC may be the same, but the MCC and/or MCC parts of the LAI will differ.
This leads to the likelihood that the eNodeB needs to dimension software/hardware resources for one counter for each Location Area.
However, there are up to 216 Location Areas per network, and, the need to accommodate some national roaming scenarios (where one PLMN is effectively using more than one MNC) and “trans border operator groups” means that the eNodeB might need one location code counter for every LAI—e.g. for up to (1 million*216) (as MNC and MCC are both potentially 3 digit numbers). This amounts to an excessive number of counters!
An object of the invention is to address or at least mitigate the abovementioned problems.